IMS is a hierarchical database management system (HDBMS) developed by International Business Machines Corporation. IMS has wide spread usage in many large enterprises where high transaction volume, reliability, availability and scaleability are of the utmost importance. While IMS provides the software and interfaces for running the businesses of many of the world's large corporations, a company typically makes a significant investment in IMS application programs in order to have IMS perform useful work for the enterprise. IMS application programs are typically coded in COBOL, PL/I, C, PASCAL or assembly language. These application programs perform IMS database functions by making Data Language One (DL/I) calls to invoke the needed IMS processing.
Sometimes an application program is custom developed by a company for its exclusive use on a particular IMS system. However, there is a different class of application programs known in the art as tools, utilities, or utility programs (henceforth referred to as utility programs). These utility programs are frequently developed by a software provider to perform tasks that are very common for many IMS installations, thereby saving a significant amount of work otherwise expended in developing custom applications to perform very common tasks. For example, unloading and reloading IMS databases for the purposes of backup/recovery or performance tuning are very common tasks for which numerous utility programs have been developed.
The use of these utility programs may save significant time when compared to the laborious process of developing comparable custom application programs. However, the ease with which these utility programs are deployed can be greatly improved. Problems may occur because the developer of a utility program typically has little or no knowledge of the form of specific IMS data structures or constructs (henceforth referred to as constructs) associated with IMS resources that exist for a particular IMS installation in which the utility program is intended to execute. Indeed, a software provider typically intends that a utility program be deployed across numerous IMS systems over various times resulting in significant unpredictability about the nature of the IMS constructs that may exist during the utility program's execution on a particular system at a given time. While the above problems may occur with any IMS application program, they are more likely to occur in conjunction with utility programs where the potential for a wider scope of deployment results in an increased diversity of encountered IMS construct forms.
These compatibility issues may force a user of a prior art utility program to create or modify the needed IMS constructs to conform with the requirements of the utility program. Adhering to these requirements prior to using the utility program may present problems to the user. First, making custom adjustments to the IMS constructs to adhere to the utility program requirements typically involves contacting an IMS database administrator with the specialized knowledge and authorization necessary to make these changes. The IMS database administrator may not be immediately available to perform such tasks, potentially resulting in even further delays beyond that which the actual work requires. Second, this process is error prone because of the great precision required when making changes to IMS constructs and the additional communication required between the utility program user and the database administrator. Further, the exacting requirements of a utility program are not always clearly documented, nor are they always noticed, potentially resulting in the discovery of these requirements only after encountering disruptive error conditions when trying to execute the utility program.
Typically, using an IMS utility program for the first time involves completing a PSB generation process (PSBGEN) to create PSB and PCB constructs for required IMS resources that are compatible in form with the utility program requirements. Form compatibility considerations include a specification of language, such as assembly language or COBOL, the coding of various compatibility specifications, as well as the order, quantity and types of PCB constructs to be included for the PSB. Performing these tasks is particularly annoying to a user if all of this effort must be taken even though the needed PSB and PCB constructs already exist (but are simply in the wrong form with respect to the utility program requirements.)
These problems have been recognized in the past and several attempts have been made to resolve them. For example, a Language Environment (LE) DL/I call was developed to address language compatibility problems. This interface, known in the art as CEETDLI, allows the IMS application program to achieve language independence. However, the interface only partially resolves all of the above identified problems and additionally introduces another weakness. Namely, this solution is only practical if the developer's IMS system and all target IMS systems on which the application program may eventually execute are enabled for LE processing. It is frequently impractical for a software provider to know this information in advance.
Another DL/I call has been developed, known in the art as AIBTDLI, as an attempt to address these problems. This interface allows the programmer to pass the name of the required PCB rather than having to predetermine the PCB order such that the correct PCB address could be determined from the list of passed PCB addresses. This interface falls far short of a complete solution to the above identified problems. First, this interface does not address language incompatibilities. Second, as with CEETDLI, a new similar problem is introduced in that to use this facility special requirements must be adhered to when performing the PSBGEN, such as specifying a “PCBNAME=” parameter. Thus, even if the languages were compatible, the absence of the “PCBNAME=” parameter requires that a new PSBGEN be performed in order to comply with the requirements of the AIBTDLI interface.
Other DL/I calls are known in the art; however, all of these calls are language dependent and also require that specific PCB addresses are passed in a specified predetermined order. These calls are known as ASMTDLI, PASTDLI, PLITDLI, CBLTDLI, and CTDLI for use with programming languages Assembly Language, PASCAL, PL/I, COBOL and C, respectively.